Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0120/206.txt

Text File | 1997-04-16 | 34KB | 761 lines

Info-Atari16 Digest         Fri, 12 Apr 91       Volume 91 : Issue 206

Today's Topics:
                            1.2 GIG drive
                         Atari cpu evolution
                     CAD 3D create and read in C?
                         Defunct Power Supply
                           Flash & QuickST
                     Flash and QuickST, continued
                          Forem BBS for sale
                         Okami English manual
                           PgC 7600 details
                         PostScript printing
                      Shareware and programming
                  SIMPLE terminal emulator (2 msgs)
                            SPURT (2 msgs)
                           ST and RC stuff
                    The language named C (2 msgs)
                           TOS 2.05 bugfix
                         ZEST [really EMULA]

Welcome to the Info-Atari16 Digest.  The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out.  Please send notifications about broken digests or bogus messages
to [e-mail].

Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
instead of the moderators are likely to be lost or ignored.

If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------

Date: 12 Apr 91 00:50:18 GMT
From:
 noao!ncar!asuvax!ukma!rex!wuarchive!uwm.edu!ogicse!milton![e-mail]
 (Alex Danilchik)
Subject: 1.2 GIG drive
To: [e-mail]

I have the chance to get a deal on a 1.2 gig Micropolis..

Anybody know if currect versions of Supra (which i have)
or ICD or BMS  and TOS 1.4 (of course) can handle
a drive this large?

cheers!
gunnar
[e-mail]

------------------------------

Date: 9 Apr 91 22:47:00 GMT
From: mcsun!ukc!slxsys!ibmpcug!mantis!mwowm![e-mail] (mathew)
Subject: Atari cpu evolution
To: [e-mail]

In <[e-mail]>, Keith Bedford writes:
>Re the Pgc cpu - see Byte March 89 (maybe only the International edition?)
>for more details.

Indeed, it's only in the "International" edition, since it's a well-known
fact that Americans aren't the slightest bit interested in anything which
is happening in Europe.

The so-called "International" section of Byte is one of the many reasons
why the magazine sucks.


mathew
--
If you're a fan of John Foxx, please mail me.

------------------------------

Date: 12 Apr 91 04:22:14 GMT
From: noao!ncar!elroy.jpl.nasa.gov!usc!jarthur!ucivax![e-mail]
Subject: CAD 3D create and read in C?
To: [e-mail]

Can somebody please send me some examples in C source on how to
create and playback DLT files (CAD 3D animation file)???  For
example, how do you XOR two frames together to get the difference and
then how do you playback the file??


Thanks in advance



Bill Ferrer
[e-mail]

------------------------------

Date: Fri, 12 Apr 91  11:17 GMT
From: MIKE <[e-mail]>
Subject: Defunct Power Supply
To: [e-mail]

   I have an early St (1985) with an external power supply. This is now
 defunct,in that the +5v output no longer works. Does anyone know if I can get a
 new
supply, or point me in the right direction for repairing it. Sources for a new
power supply would be preferable in the U.K. but I'm open to suggestions.

Thanks

Mike Jenkins  ([e-mail])

------------------------------

Date: Thu, 11 Apr 91 22:41:15 edt
From: [e-mail] (A.S.T.R.E.)
Subject: Flash & QuickST
To: [e-mail]

Steven,

   I've seen that problem, too.  I'm using Flash 1.62 and QuickST 2.00 on a
monochrome monitor.  It seems to be a problem with VT-52/100, as I think I've
also seen it occur with UniTerm and Atari's VT-52 emulator DA.  It's not that
bad if the screen is scrolling (basically it leaves a big ugly cursor mark
somewhere every few lines), but it's a nuisance otherwise (anyone play
Axotoxl [sp?] Football League on BBS's?  big problem there!).

   My solution is to use SuperBoot to configure my auto/DA files so that, if
I'm going to be telecomming

------------------------------

Date: Thu, 11 Apr 91 22:48:06 edt
From: [e-mail] (A.S.T.R.E.)
Subject: Flash and QuickST, continued
To: [e-mail]

   ...sorry we were interupted

if I'm going to be telecomming, I have a particular keystroke set to GEMSTART
Flash and *not* to \AUTO\ QuickST.  Once I'm done, I reboot (va UIS warm
reboot) and select a config with QuickST running.  With a HD, it only takes
about 10-15 seconds and a few keystrokes, so it's not too bad.

   The moral of this story is: try out SuperBoot (ver. 7.0 was just released
about a month ago) if you need to reconfig your \AUTOs or DAs to get around
this (or if you use GDOS or if you use OMNIRES or if...)

     //////////////////////////////////////////////////////////////////////
    //      Jeff Vincent / ASTRE      //  ASTRE = Competition Rocketry  //
   //  [e-mail]  //     Publisher of STAR-DATE     //
  //------------------------------------------------------------------//
 //          "So, like, do you guys ride in these things?"           //
//////////////////////////////////////////////////////////////////////

And it wouldn't hurt if one (or both) of us sent a bug report to Darek...

------------------------------

Date: 12 Apr 91 06:27:06 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!jarthur!petunia!csuchico.edu!ekrimen@arizona.e
 du (Ed Krimen)
Subject: Forem BBS for sale
To: [e-mail]

$30 takes it.  Willing to trade.

--
         Ed Krimen  ...............................................
   |||   Video Production Major, California State University, Chico
   |||   INTERNET: [e-mail]  FREENET: al661
  / | \  SysOp, Fuji BBS: 916-894-1261        FIDONET: 1:119/4.0

------------------------------

Date: 12 Apr 91 06:31:01 GMT
From:
 noao!asuvax!cs.utexas.edu!swrinde!mips!spool.mu.edu!munnari.oz.au!goanna!minyos
 .xx.rmit.oz.au![e-mail] (Tehn Chin)
Subject: Okami English manual
To: [e-mail]

Have just downloaded the Okami Shell from atari.archives. I am slightly
confused in using it as the manual is in German. I was wondering if there
is a english version of the manual.

Thanks in advance.
Reply via news group
--------------------------------------------------------------------------
Tehn Yit Chin
[e-mail]

"Don't take any shit from anyone!" - Billy Joel, Live at Yankee Stadium
--------------------------------------------------------------------------

------------------------------

Date: 12 Apr 91 08:47:40 GMT
From: munnari.oz.au!uhccux!uhunix1.uhcc.Hawaii.Edu![e-mail]
Subject: PgC 7600 details
To: [e-mail]

The following information is from the international edition of BYTE magazine's
March '91 issue.  Back issues are available by calling BYTE at [phone].

The international edition adds about 150 pages to the U.S. version of BYTE
and contains many ads and product announcements of firms participating at the
CeBIT Hannover Fair.  Two articles by Dick Pountain, Byte's contributing editor
in London, concern the PgC 7600 RISC and the Taos multiprocessing OS.  The
PgC 7600 is touted as a second-generation RISC processor capable of 160 MIPS,
Intel 80x86 emulation and embedded control.  The chip will reportedly sell, in
quantity, for $20.

The Taos OS may also be of interest to this newsgroup, not only because of its
ability to run identical code on different processers, but also because it in-
fluenced design changes in the PgC 7600 processor. One of the architects of
the Taos OS, Chris Hinley, is also experienced in writing games for the Atari ST
and Amiga (Verminator and Onslaught).  His technique of using object-oriented
assembly language with a large number of macro libraries in game design was
used in the construction of Taos.  A fellow programmer, Nick Spicer, is using
his knowledge of transputers to implement parallel processing capabilities.
For further information, refer to the article starting on page 90IS-117 of the
international edition of the March '91 BYTE.

The following article on the Pgc 7600 is actually about three pages long.

-------------------------[excerpt of PgC 7600 article]-------------------------

[ The  PgC 7600  RISC processor  is the result  of a collaboration  between
Chris Shelton and Sir Clive Sinclair, two computer designers.  Shelton is known
in the U.K. as the designer of the Nascom and SigNet computers.  The Nascom
was a single-board computer, while the SigNet allowed multiple users to connect
with a network of close-coupled Z80 processors.  Sinclair is known worldwide
for his inexpensive, yet capable microcomputers, as well as many other inven-
tions.  Sinclair and Shelton's goal is to produce an ultra-low cost workstation
by basing it on a chip that integrated computational, memory and video RAM con-
trol, networking, and timer logic. ]

The processor, code-named PgC7600, has been in development since 1988 by a
small team led by Shelton and financed mainly by Sinclair.   Computer simu-
lations of the chip were completed by July 1989  and masks for making it by
March '90.  First samples failed because of a process fault, and second samples
revealed a flaw in the RAM interface.   I had timed this article to coincide
with the delivery of third (working) samples of the chip, but these have been
delayed.  Hopefully, a PgC7600 will be running by the time this article is
published.

The key idea behind its design is that speeding up a RISC processor eventually
takes you to a point at which you cannot keep up with getting signals on and
off the chip.  Shelton therefore decided to isolate the RISC CPU by completely
surrounding it with on-chip peripheral-control units that handle all the comm-
unications with the outside world (e.g., memory accesses, interrupts and I/O
channels).  The PgC contains on-chip timers video RAM support, interrupt vector
generation, DMA, an I2C bus for LANS, and a memory controller (MCU) which can
refresh dynamic memories.

All the PgC's interfaces to the outside world have been optimized for speed.
For example, the chip uses unbuffered static-column mode for RAM accesses and
a small but ingenious on-chip cache (called the Q-cache) to keep the processor
fed with instructions.  In addition, to further improve the memory bandwidth
for instruction fetches, the PgC has a simple RISC core processor with about
100 instructions, almost all of which are 1 byte long.

To achieve the performance (in excess of 160 MIPS) that he believes is required
to emulate other commercial CPUs in software,  Shelton is implementing the PgC
7600 in a bipolar process.  Because of its high power consumption,  however,
bipolar technology has been completely supplanted by MOS technologies.

It does have its advantages: it is faster than MOS and scales down better to
submicron sizes.  Also, because it is current-switching rather than voltage-
switching, it can drive low-impedance loads like CPU pins faster than MOS can,
bringing benefits in better CPU-memory bandwidth.  PgC skirts the power con-
sumption problem by reducing a logic transition to 0.25 volt instead of the
standard TTL 5 volt, which reduces the energy dissipation by a factor of 400.

The process that PgC uses is one originally developed by Ferranti (now Plessey-
GEC), called the Collector Depletor Isolation (CDI).  It offers access times
of 2.5 ns at the modest 1.2 micron scale.  The PgC7600 will be implemented
initially as a gate array that occupies a 10 by 10 mm silicon chip, but this
could be reduced to 7 by 7 mm with a custom layout.  Some 33% of the chip area
is RAM and ROM.  In CMOS, Shelton believes that the 6000 gate chip could be
implemented on a 2 by 2 mm die, but performance would fall to 60 or 70 MIPS.

The bipolar process requires fewer masks than does CMOS, so PgC hopes this will
help them produce the chip for $20 in quantity.  This, in conjunction with the
fact that it requires few glue-logic chips, could make it attractive as an em-
bedded controller as well as an almost glue-less CPU for low-cost workstations.

The prototype PgC7600 has an integer CPU that is expected to operate at about
160 MIPS.  There is no on-chip FPU.  The CPU is provided with 40 registers,
divided into five banks of eight.  All are 32 bits wide and can be accessed in
2.5 ns, giving a processor cycle time of about 5 ns.

The register architecture is designed to be scalable in future versions while
maintaining compatibility with earlier versions.  To achieve this, the register
banks are named 0, 1, 2, 3, and TOP.  When an interrupt is serviced, state
information such as the accumulator and pc contents are saved only in the TOP
register bank.  Designers could add more banks (numbered as 0, 1, 2, 3, 4, 5
and TOP) without causing programs written for earlier versions to break.

The Q-cache is a fast (2.5 ns) on-chip RAM that is 32 bytes long and can,
therefore, hold an average of 32 instructions.  In hardware terms, the Q-cache
is implemented as a circular buffer.  During sequential program execution, it
gets reloaded in single-word (32-bit) chunks, thereby acting as a 32-byte
moving window into main memory.  When a branch instruction causes the cache to
become invalid, it gets reloaded in 64-bit chunks, and each chunk can start
executing while the next one is loading.  Like the register architecture, the
Q-cache is transparently scalable for future chip versions.

The MCU is described in PgC's documentation as aggressive, and this is no exag-
geration.  It controls most of the PgC7600's 84 external pins, and it features
separate address and data buses.  The MCU uses every possible technique to
optimize access to ordinary DRAM, and it supports the static-column and fast-
page modes of modern DRAM chips as well as SRAM.  These modes (also supported
by the Acorn ARM and Intel i860) typically allow 512 consecutive data words to
be accessed from the same row of a RAM chip.  For inexpensive 100 ns access-
time DRAM chips, the row-address select cycle time may be as much as 180 ns,
but the column-access select cycle is only 55 ns, becoming the effective cycle
time.  The PgC generates its CAS/RAS multiplexer signals on-chip, so they add
only 3 ns to the cycle time.  The use of a bipolar drive for the pins allows
the MCU to access memory without buffering, saving even more time.

The MCU is the only part of the PgC7600 that depends on external timing.  With
a 16 Mhz clock, it should achieve a 25 ns cycle time with 15 ns SRAM and a 50
ns cycle time with 80 ns DRAM, providing a bandwidth between 160 and 80 mega-
bytes per second.

Although the original requirements for the PgC7600 to act as a full graphics
processor was abandoned, the final design can still act as an integrated CRT
controller.  A dedicated interrupt causes a jump into a ROM subroutine, which
grabs a video address from the TOP register bank, puts it into the MCU, and
then requests a VRAM access cycle.  Control then returns to external code,
which computes the next video address.  If you put your video-synchronous sig-
nal onto this interrupt pin, the PgC7600 becomes a CRT controller for video
buffers implemented with VRAM chips.  Shelton estimates that controlling a
1024 by 768 pixel by 8-bit video buffer in this way would consume about 1 per-
cent of CPU time.

The original purpose of the high performance promised by the PgC7600 was for
full-speed emulation of other processors, especially the Intel 8086 family,
in software, allowing the chip to drive a low-cost IBM PC-compatible work-
station.  However, PgC is now envisaging broader applications.  Though the
chip does not have special communication hardware like that of the Inmos
transputer, its fast memory access would enable it to be used in parallel-
processing systems where shared memory is the communication channel between
processors.

This sort of system would be ideal for running distributed message-passing
operating systems such as Helios or Taos (see my article: "Taos: An Innovation
in Operating Systems").  PgC has been in close contact with the developers
of both operating systems and has even modified the instruction set of the
PgC to better accommodate the Taos's message-passing scheme.

As mentioned, the Pgc7600 has no hardware for floating-point arithmetic, which
would seem to disqualify it from supercomputer applications.  However, Shelton
argues with some conviction that the superior processor-to-memory bandwidth
can be exploited here.  The Pgc7600 could feed floating-point data into pseudo-
registers held in dual-ported RAM.  From there, the data would be autonomously
transferred into a streamed FPU, such as those from AMD, Weitek, or Cyrix, and
the answers would be transferred back by the same means.  Using 15 ns SRAM
pseudo-registers, the PgC7600 should be capable of transferring data at 160
MBps (1280 Mbps).  If each floating-point operation involved 100 bits, a three-
operand scheme could sustain the quoted peak rate of the FPU, which could be up
to 33 million single-precision floating-point operations per second.  Combining
this with the parallel scheme would allow pipelines of many PgC7600s to be con-
structed to deliver supercomputer performance.

Another intriguing possibility, given Sinclair's Anamartic connections, would
be wafer-scale integration, for which the 6000 gate PgC design is an ideal can-
didate.  We'll see what happens.

----------------------------[end of excerpt]-----------------------------------

For $20, this thing sounds potent, especially in combination with the Taos OS.
The article alludes to the other ventures of Sir Clive Sinclair and I recall
that he was supposed to be developing a silicon "hard drive", so that it is
very possible that our conceptions of power and price may be radically altered.

Though I don't question Sinclair's and Shelton's genius, I have some doubts
about Sir Clive's business acumen.  The Timex, Quantum QL, Cambridge Computer,
and Psion are all pretty good machines, but they had some quirks and were not
supported by further development.

I think Atari might be in a better position to deliver and support a marketable
product based on the PgC chips, because of their experience with the Inmos
transputer and Helios OS, which culminated in the ATW computer.

For the complete article, contact BYTE Back Issues, One Phoenix Mill Lane,
Peterborough, NH  03458, [phone].  In Europe, send requests to BYTE
Back Issues, c/o Dynamic Graphics International, P.O. Box 25, 3950 AA Maarn,
The Netherlands.


Jack

------------------------------

Date: 12 Apr 91 02:36:20 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.ed
 u![e-mail] (Ryk E Spoor)
Subject: PostScript printing
To: [e-mail]

        Is there a program available anywhere that will take WordWriter
output and convert it to PostScript, suitable for LaserWriters?
        Or, alternatively, is there a program that will take WordWriter
output and convert it to either IBM WordPerfect or WordStar?
        (I have a publisher who'd be grateful if I could send the
stuff in her own format)

                                 Sea Wasp

------------------------------

Date: 12 Apr 91 06:14:21 GMT
From:
 noao!asuvax!cs.utexas.edu!swrinde!mips!cs.uoregon.edu!ogicse!unmvax!uokmax!kllo
 [e-mail] (Kenneth L Love)
Subject: Shareware and programming
To: [e-mail]

I want to program a game or two this summer (see previous message for the
language).

Does anybody have any knowledge on the concept of shareware?  Does saying
it is so in a doc file constitute it being shareware?

I would rather have the possibility of getting money for the time I spend
programming, but it wouldn't be essential.  That is what I consider to
happen when someone releases a program as shareware.  Is this what does
occur?  How often does someone get something and how good/useful does the
program have to be before one would expect to receive anything back?

That probably didn't make much sense (it doesn't to me and I just wrote
it!), but I hope somebody understands it enough to reply.

In case anybody is interested, one of the games I'm going to write is a
solitaire game that I haven't seen anywhere (it's a LOT tougher than
Klondike ever was).  If you've ever played Spider then you have a good idea
of the rules, except only one deck is used and only kings are allowed in
"spaces".  If anybody wants the rules (as taught to me), just send me some
mail.  (It really is one of the better solitaires, if you don't cheat a
lot.  When you do beat it, though... Well, you get the idea.  It's also,
IMHO, one of the most frustrating.  I have had situations where 3 of the 4
suits had been removed from the board and was left with all the rest the cards
in order [queen to ace], except the king was the last face-down card and the
queen was sitting on top it.  Since only kings can be moved to blank spots,
I lost!)

I haven't decided (yet) on the other game (it might not be a game for that
matter).  Anybody got any suggestions?  (Please consider that this will
be only my second program on the ST and in a language I will have only
started to learn this summer.  I consider myself fluent in Pascal, but
ignorant in C.)

Kenneth Love

------------------------------

Date: 12 Apr 91 02:35:20 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!spool.mu.edu!munnari.oz.au!brolga!uqc
 spe!cs.uq.oz.au![e-mail] (Warwick Allison)
Subject: SIMPLE terminal emulator
To: [e-mail]

Is there a SIMPLE terminal emulator at atari.archive?  I use Uniterm for
most things, but I'd like a REALLY simple emulator for quickly switching
back and forth from the command line (Mupfel) to the terminal emulator.
I don't want any screen clears and stuff like that, just plain AUX:<->CON:
type commumnication.  Mupfel has a variable sized Console Window, but I
can hack TERMCAP at the Uni end to correct for that.

Alternatively, is there source to a fairly simple emulator that I can strip
down somewhat?


Thanks for any info!
Warwick

--
  _--_|\        [e-mail]
 /      *  <--  Computer Science Department,
 \_.--._/       University of Queensland,
       v        AUSTRALIA.

------------------------------

Date: 12 Apr 91 08:29:35 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!samsung!olivea!mintaka!wookumz.gnu.ai
 .mit.edu![e-mail] (entropy)
Subject: SIMPLE terminal emulator
To: [e-mail]

In article <[e-mail]> [e-mail] (Warwick Allison)
 writes:

>Is there a SIMPLE terminal emulator at atari.archive?  I use Uniterm for
>most things, but I'd like a REALLY simple emulator for quickly switching
>back and forth from the command line (Mupfel) to the terminal emulator.
>I don't want any screen clears and stuff like that, just plain AUX:<->CON:
>type commumnication.  Mupfel has a variable sized Console Window, but I

Look in the directory atari/mint and you will find 2 programs that
should suit your needs, st52 by me and tip by Howard Chu.  If you need
any features at all, use Howard's program, as mine takes the
expression 'dumb terminal' very literally.

entropy

------------------------------

Date: 12 Apr 91 01:38:43 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-sta
 te.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!mts10271@arizona.e
 du (Michael T Stepniczka)
Subject: SPURT
To: [e-mail]

Just a quick question- is the SPURT file that ended up at atari.archive
incomplete? Should SPURT 1.0 have been included with it? If so, could
someone who has it please send it to the archive site. Thanks.


                                                Michael Stepniczka
                                                [e-mail]

------------------------------

Date: 12 Apr 91 04:44:40 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!jarthur!petunia!csuchico.edu![e-mail]
 (Ed Krimen)
Subject: SPURT
To: [e-mail]

In article <[e-mail]> [e-mail]
 (Michael T Stepniczka) writes:
>
>Just a quick question- is the SPURT file that ended up at atari.archive
>incomplete? Should SPURT 1.0 have been included with it? If so, could
>someone who has it please send it to the archive site. Thanks.

I sent SPURTDEM to a.a.  When I got the archive originally, that's all it had.



--
         Ed Krimen  ...............................................
   |||   Video Production Major, California State University, Chico
   |||   INTERNET: [e-mail]  FREENET: al661
  / | \  SysOp, Fuji BBS: 916-894-1261        FIDONET: 1:119/4.0

------------------------------

Date: 11 Apr 91 14:44:22 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!news-serv
 er.csri.toronto.edu!torsqnt!jtsv16!lsuc![e-mail] (Jim Omura)
Subject: ST and RC stuff
To: [e-mail]

1991/04/10

Atari ST and RC:

1.   My article called "Bolink Rebirth" was published in the March
1991 issue of "Competition Plus".  This is a magazine for Radio
Controlled model car racing.  The Atari 1040ST with Drafix 1 software
and the Toshiba P321 printer are featured in that article as being
the tools used to develop parts designs.

2.   In the May 1991 issue of "Model Airplane News", Bill Griggs
reviews the "R/C Aerochopper" simulator which runs on the Atari
ST with a special dual, full proportional, joystick system.
This simulator is distributed in the US by Futaba.

3.   I received my update for Spectum Holobytes' "Falcon" F-16
simulator 2 days ago and I've run it on the 1040ST with TOS 1.4.
It's working fine overall.  The software still seems to have
some operational rough spots.  I've found that occasionally the
disk "active" light will stay on when it shouldn't, but so far
it's not happened in such a way that I couldn't "force" it off.
This should NOT be necessary.  I find this a bit discouraging.
In dealing with a 3rd generation (version 1.2) of a commercial
piece of software on a common and fairly standard system (the
system was an unmodified 1040STF with TOS 1.4, an Atari original
SF314 floppy and SC1224 monitor being the only active attachments),
I don't think I should find fairly obvious functional bugs within
the first minute of use.  But aside from that I'm now having fun
learning all about the F-16.  According to the update erata sheet
the "R/C Aerochopper" joystick system I mentioned above works
with "Falcon".  There's no mention of the STE 15 pin joysticks.
One would hope that they'll have them supported in the future.
--
Jim Omura, 2A King George's Drive, Toronto, [phone]
lsuc!jimomura
Byte Information eXchange: jimomura

------------------------------

Date: 12 Apr 91 05:47:54 GMT
From: noao!ncar!unmvax!uokmax![e-mail] (Kenneth L Love)
Subject: The language named C
To: [e-mail]

This summer I'm going to be teaching myself how to program in C.  My
biggest (and brightest?) question is:  "Which version of C is the best?".

I realize that many factors could influence my (or someone else's) opinion.
So, I'm going to list a few.

The code must be somewhat portable between systems (i.e. Is there a standard
and how far do the ST versions diverge from it?)

The company support must be existant.

Are there good books available for the learning of this version of C?
(Or would any book on C be sufficient?)

Would it be better if I knew something about the internals of the ST?
(Is C like Pascal in that knowing the system hardware is uneccesary?)

If I am fluent in Pascal, how difficult is C to learn?
(Are they different conceptually?  i.e. pointers = what in C?  Does C have
 some things that Pascal doesn't?  etc.)

Is Turbo C going to be released in English?  (I have NO desire to learn
German, especially if all I was going to do with it was work with Turbo.)

What kind of editor do the various versions use?  (I like 'vi' over 'ed'
anyday! :)  (Is the mouse supported?)

Does C use anything like a CLI or is it GEM only?  (I use 'csh' on the Unix
system here at Okla. U.  Does C use a shell like 'csh'?)

Can I use any of the versions of C without a hard drive?  (I don't have
one and it may be next fall before I do get one.)

How much does the language(s) and book(s) cost?

That's all I can think of.  (I think I hear cries of, "Isn't that enough?"...
Nahhh... Couldn't be! :)

adTHANKSvance,
Kenneth Love

------------------------------

Date: 12 Apr 91 06:21:06 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!unmvax!uokmax!k
 [e-mail] (Kenneth L Love)
Subject: The language named C
To: [e-mail]

In article <[e-mail]>
 [e-mail] (Kenneth L Love) writes:
>
>This summer I'm going to be teaching myself how to program in C.  My
>biggest (and brightest?) question is:  "Which version of C is the best?".
>
[ Stuff deleted ]
>
>adTHANKSvance,
>Kenneth Love

I forgot to mention that I would prefer to receive e-mail on this.

I thought of another question:  Does anybody have any well documented C
source code for playing with graphics and sound on the ST?  Would this
probably be helpful in learning what the ST's ranges are?  Should I get
some other book(s) about the ST's capabilities?

Thanx again,
Kenneth Love

------------------------------

Date: 12 Apr 91 00:21:17 GMT
From: fernwood!portal!atari![e-mail] (Allan Pratt)
Subject: TOS 2.05 bugfix
To: [e-mail]

[e-mail] (LarsErikOsterud) writes:

>While testing out my new MEGA STE i discovered a nasty bug in one
>of the Xbios routines (I can't understand why no beta-tester has).

Maybe because it's not a bug.

>The XBIOS 5 call  setscreen(logadr,physadr,resolution)
>is used to set screen adresses and change screen resolution.

>The routine does NOT wait for vertical blank as it i supposed to
>but resets the video in the middle of the screen, causing the
>picture to wrap around the left edge of the screen in 50% of
>the cases.  This does not look good (you get the edge of the
>grapic screen in the middle of the monitor screen :-)

Thank you for starting a panic.  I think it is not a bug but a problem with
your Mega STe.  I can not reproduce the "bug" you report.  It might have
occurred to you that your Mega STe is to blame, not TOS.

Your lack of understanding of the reasons for the protection code in the
ROM has led you to a false conclusion.  To nip this in the bud, I'll
explain.  The shifter mode must not be changed during a critical moment
around vertical blanking.  Previously that was avoided by waiting for the
vblank interrupt, which ensures that the critical moment has passed.  The
new code uses another method: it checks to be sure that you are in the
middle of the screen someplace, not in vblank.  The upshot is the same: you
avoid the window of vulnerability.

If you had named the programs that caused trouble this would have been a
more useful bug report.  It is possible that there is an interaction
between those programs and the new code.  Please post or mail me the names
of those programs.

If this turns out to be a real live software bug, I will eat my words.

(Lars-Erik has responded to me in mail about the programs (e.g. Degas
Elite) and I have suggested that he return the machine to his dealer. This
posting is for everybody else, so you don't think we're totally out to
lunch when it comes to testing software.)

============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt

------------------------------

Date: 11 Apr 91 21:11:53 GMT
From: fernwood!portal!atari![e-mail] (Allan Pratt)
Subject: ZEST [really EMULA]
To: [e-mail]

Thank you for my smile of the day!

>       One word about EMULA, make sure you put this on a floppy AUTO folder
>not your Hard drive, it does some funky stuff that will probably conflict
>with other AUTOboot prgs and perhaps fry your Hard Drive.

>Have Fun!!!

Yeah, right.  This is what I call quality software.  Can't wait to run THIS
program in my AUTO folder!  Does anybody else consider this offhand caveat
funny?

============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt

------------------------------

End of Info-Atari16 Digest
******************************